The DMX communication protocol is a lighting command protocol conventionally employed in the lighting industry for some programmable lighting applications and currently includes the DMX512 and DMX512-A protocols. In the DMX protocol, lighting related instructions may be transmitted to a lighting unit as control data that is formatted into packets including up to 512 bytes of data, in which each data byte is constituted by 8-bits representing a digital value of between zero and 255. Each 8-bits of data are preceded by a single Start Bit and followed by two Stop Bits to form what is referred to as a data slot (size 11 bits). These 512 data slots are preceded by a “start code” byte (typically 0x00) also referred to as slot 0 which has its own Start Bit followed by 8-bits of data (typically 0x00) then two Stop Bits. The “start code” is preceded by a Break and a Mark-after-Break.
In the DMX protocol, an individual data slot of the up to 512 data slots in a given DMX packet is intended as a lighting related command for a particular lighting unit. For example, the 8-bits of data within an individual data slot may be intended as a command for a particular “channel” of a multi-channel lighting unit, wherein a digital value of zero indicates no radiant output power for a given channel of the lighting unit (i.e., channel off), and a digital value of 255 indicates full radiant output power (100% available power) for the given channel of the lighting unit (i.e., channel full on). For example, considering for the moment a three-channel lighting unit based on red, green and blue LEDs (i.e., an “R-G-B” lighting unit), a lighting command in DMX protocol may specify each of a red channel command, a green channel command, and a blue channel command as eight-bit data (i.e., a data byte) representing a value from 0 to 255. The maximum value of 255 for any one of the color channels instructs a processor of the lighting unit to control the corresponding light source(s) to operate at maximum available power (i.e., 100%) for the channel, thereby generating the maximum available radiant power for that color (such a command structure for an R-G-B lighting unit commonly is referred to as 24-bit color control). Hence, a command of the format [R, G, B]=[255, 255, 255] would cause the lighting unit to generate maximum radiant power for each of red, green and blue light (thereby creating white light). For finer resolution color control more than the 8-bits of data in a single data slot could be used, for example, sixteen bit color luminaires using two data slots so as to represent a value from 0 to 65535. Not just R-G-B lighting is considered but also larger numbers of colors such as, but not exclusively limited to, Red-Green-Blue-Amber-White.
Also, for example, all or aspects of an individual data byte may within a data slot may also be intended as a command to control one or more additional aspects of a lighting unit and/or other DMX slave device. For example, one or more data bytes may control pattern, focus, prism, pan, tilt, rotation speed, and/or animation of a lighting unit. Also, for example, one or more data bytes may control a dimming shutter, color wheel, and/or framing lens of a lighting unit. As understood by one of ordinary skill in the art, the DMX protocol may additionally or alternatively be utilized to control other aspects of one or more lighting units and/or other DMX slave devices.
Thus, a given communication link employing the DMX protocol conventionally can support up to 512 different lighting unit channels. A given lighting unit designed to receive communications formatted in the DMX protocol generally is configured to respond to only one or more particular data bytes of the 512 bytes of data in the packet corresponding to the number of channels of the lighting unit (e.g., in the example of a three-channel lighting unit, three bytes are used by the lighting unit), and ignore the other bytes, based on a particular position of the desired data byte(s) in the overall sequence of the up to 512 data bytes in the packet. To this end, DMX-based lighting units may be equipped with an address selection mechanism that may be manually set by a user/installer to determine the particular position of the data byte(s) that the lighting unit responds to in a given DMX packet. Other systems may make use of the bi-directional communications capabilities provided for in the ANSI E1.20-2006, Entertainment Technology—RDM—Remote Device Management over DMX512 Networks standard to remotely configure DMX addresses.
Certain implementations of the DMX protocol involve use of the protocol outside of its original scope and/or the stretching of the capabilities of the protocol. For example, the DMX protocol is being utilized over a wireless network in some implementations. Also, for example, the DMX protocol is utilized to control lighting units that may put people and/or property at risk in some implementations (e.g., eye damaging laser emitting lighting units utilized around people). In such implementations, and in other implementations of the DMX protocol, it may be desirable to implement error detection and/or correction to improve reliability, functionality, and/or safety of lighting units.
The DMX512 protocol does not provide for error detection. The DMX512-A protocol mentions error detection via use of a System Information Packet (SIP). The SIP has an alternate start code (e.g., 0xCF i.e. 207) and includes checksum data relating to the previous DMX packet on the data link, along with other control information. Although the SIP implements some degree of error detection, utilization thereof requires all DMX slave devices to be compatible with the DMX512-A protocol. Also, the checksum included in the SIP must be sent in a separate packet. Also, the SIP does not implement any error correction.
Thus, there is a need in the art to provide methods and apparatus related to extensions of the DMX protocol that enable error detection and correction by enhanced DMX slave devices and that optionally overcome one or more additional drawbacks of a SIP.